home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000338_K.Hoadley@directory.rl.ac.uk _Wed Nov 18 13:28:18 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Return-Path: <K.Hoadley@directory.rl.ac.uk>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA08640; Wed, 18 Nov 92 13:28:18 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA28165; Wed, 18 Nov 92 12:08:54 +0100
  6. Received: from danton.cc.rl.ac.uk by directory.rl.ac.uk with SMTP (PP) 
  7.           id <09533-0@directory.rl.ac.uk>; Wed, 18 Nov 1992 10:56:46 +0000
  8. Date: Wed, 18 Nov 1992 10:04:15 +0000 (GMT)
  9. From: Kevin Hoadley <K.Hoadley@directory.rl.ac.uk>
  10. Reply-To: K.Hoadley@directory.rl.ac.uk
  11. Subject: Smart server or smart client ?
  12. To: www-talk@nxoc01.cern.ch
  13. In-Reply-To: Putz.parc@xerox.com's message of Tue, 17 Nov 1992 12:13:13 PST: <92Nov17.121323pst.58401@spoggles.parc.xerox.com>
  14. Message-Id: <Ximap.722084834.9952.khoadley@danton>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17.  
  18. Steve Putz wrote:
  19. >I like the idea of your suggested INPUT tag.  It seems like a logical
  20. >extension of the current protocol, and I can think of many uses for it,
  21. >including form-based queries and maybe even a server-based Hypertext editor
  22.                                                =============================
  23. >running on a very simple generic client.
  24. >
  25. >Steve Putz
  26. >Xerox PARC
  27. >
  28. >
  29. This raises the question of smart servers vs smart clients.
  30.  
  31. How much does the client need to know about format conversion ? The client
  32. knows what formats it understands (maybe extensible through a system like
  33. a MIME mailcap), but does it need to know about how to convert between
  34. different formats ? Adding format conversion into the clients will make
  35. them much more complicated, which is usually not a good thing (witness
  36. the success of POP over IMAP in the PC mail market: POP is simple minded,
  37. easy to implement and as a result widespread; IMAP is a rather nice protocol,
  38. fairly powerful, but more difficult to implement (though not THAT difficult).
  39. RESULT: though IMAP is technically far superior to POP, POP is winning
  40. the war.)
  41.  
  42. Thus I think it would be a good idea to keep the clients simple, shunt
  43. the complexity where possible into the server (it doesnt matter much if
  44. ther are only one or two server implementations; it matters a great deal
  45. however if the clients are only limited to certain Unix boxes).
  46.  
  47. I think we can learn from the way the DNS works. The are two types of DNS
  48. queries: iterative and recursive. With an iterative query, the client
  49. (resolver) sends a query to one server. From the result it may be referred
  50. to another server, which it then queries and so on until it reaches a 
  51. conclusion. With a recursive query, the resolver (a stub resolver) sends
  52. the initial query (with the RR bit set) to a local server, which then does
  53. all the work. The protocol remains the same in both cases, the actual
  54. procedure of lookup remains the same, they differ only in whether the local
  55. resolver does all the work or simply punts it to a local server.
  56.  
  57. The best way to support small machines such as PCs, Macs, Amigas etc
  58. within the WWW would seem to me to support the concept of a stub client
  59. that merely throws everything at the server and leaves it to sort out the
  60. mess. When the stub client connects to the server it informs the server
  61. what formats it understands (lists out its wwwcap ?). Compatibility with
  62. existing clients can be maintained in that if a client doesn't inform the
  63. server of the formats it knows, we can asssume a minimum (HTML + plain
  64. text ?).
  65.  
  66. This can be extended further... consider a site running a firewall,
  67. limiting access to the outside to a few selected hosts (poor misguided
  68. people !). If I'm sitting on a PC and I'm reading a document with a link
  69. to another document outside my site, that link is useless to me because
  70. I cant access the outside world. On the other hand a central site server
  71. might have external access, thus if I can punt the query to the server
  72. and say "you go fetch this for me" everything is hunkydory. The underlying
  73. protocol doesn't change, all that happens is that I can ask any server
  74. to get me the answer, rather than just the right one.
  75.  
  76. Again look at the DNS. The great advantage of stub resolver is that they
  77. lead to a centralised cache at the local server. If we punt www queries
  78. to a local server we get the same: the ability to build a cache of the
  79. information regularly used by the locals (I'm writing from a research lab
  80. with a heavy slant towards high energy physics - thus there is likely
  81. to a slant in the documents that users around here want; cacheing this
  82. working set would be a big win.)
  83. (For this cacheing to work well we'd need to associate a time to live
  84. with each document - again like the DNS).
  85. It should be possible to cache format conversions as well.
  86.  
  87. Anyway, these are just some ideas, maybe useful maybe not.
  88.  
  89. Kevin Hoadley, Rutherford Appleton Laboratory, khoadley@ib.rl.ac.uk
  90.  
  91.